As of 2016-02-26, there will be no more posts for this blog. s/blog/pba/
Showing posts with label desktop environment. Show all posts

The title of this post doesn't mean anything for real.

About a week ago, someone posted Merging: udev and systemd about Udev and systemd to merge. I don't really care about this merge because:

After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially.

There is no need for me to concern about this, even though there were some stirring discussions over this. As long as I don't need to do extra configuration, then I am okay with it. The only drawback is the tarball will be bigger, don't know how big it would be, never use systemd before and I have no need. But if this will make the development easier, then I won't fuss over it.

One comment on LWN.net mentioned Zawinski's Law:

Zawinski's Law of Software Envelopment (also known as Zawinski's Law) relates the pressure of popularity to the phenomenon of software bloat:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Examples of the law in action include Emacs, MATLAB, Mozilla and Opera.

This law is attributed to Jamie Zawinski, who popularized it. It may have been inspired by the humorous Law of Software Development and Envelopment at MIT, which was posted on Usenet in 1989 by Greg Kuperberg, who wrote:
Every program in development at MIT expands until it can read mail.

I found this is pretty amusing and somewhat true, but can MATLAB really read mail? Well, not directly, but you can sendmail for sure. I don't feel surprised when I saw Emacs in the list, though I don't really know if it can read mail or not. But once a while, I would stumble across stuff about the bloat of it.

Two replies mentioned about GNOME5 and The Registry, quite sure it was meant to mock around Windows Registry. They are just for laughter, nothing really serious about it, but that doesn't mean they are not true.

But this comment referred to the future of GNOME did cause me thinking:

For Debian perhaps. However, I don't think this is true for GNOME. The future of GNOME is as a Linux based OS. It is harmful to pretend that you are writing the OS core to work on any number of different kernels, user space subsystem combinations, and core libraries. That said, there may be value in defining an application development platform or SDK that exposes higher level, more consistent, and coherent API. But that is a separate issue from how we write core GNOME components like the System Settings.

It is free software and people are free to port GNOME to any other architecture or try to exchange kernels or whatever. But that is silly for us to worry about.

Kernels just aren't that interesting. Linux isn't an OS. Now it is our job to try to build one - finally. Let's do it.

I think the time has come for GNOME to embrace Linux a bit more boldly.

Some people would have strong concern about it if this is real future of GNOME, especially people who use GNOME and already think GNOME is a colossal environment . Some may like the way it goes as becoming an OS, some may think it should not go that way.

I like the way current Linux is. Yes, things are broken sometimes and you may need to put efforts in it if you really care about. Things are pretty complicated, but by having such goal, can you be sure you won't become another same Linux problem which you think Linux currently is having?

You write code which you think they should be in OS core and bring up the issue across different layers of coding. If you look from another perspective, maybe that's because you shouldn't do things that requires such code? I think this somehow resonates with Zawinski's Law. You program expands to where it shouldn't be to. You definitely know you shouldn't, but you still go there anyway.

I stopped using GNOME for at least three years, it had too many stuff I don't need and don't even know they were sitting in my system. I am not entirely sure what it really is, still a Desktop Environment? Same thought goes to KDE, I think KDE could be even bigger than GNOME.

If GNOME evolves into an OS, I won't object it, but they can't be associated with the name "Linux" at all, even it includes Linux kernel within. It would be a new OS, no way you should call it Linux. It's not Linux, it would've gone from Linux road. Not even a Linux distribution, that GNOME will not be qualified for being titled with "Linux" or "Distribution."

Desktop Environment (DE) is a loose term, you can define it with almost everything included or almost nothing, possibly boiling down to just a Window Manager (WM). In fact, you can even argue what should be in a WM. DE and WM would grow as other programs do, that's one of reason that I switched to DWM. Occasionally, people fork DWM and try to make more smaller version of it. I guess DWM is still too bloated for some.

The true issue I have with GNOME is dependency. Even I don't have GNOME installed, I still have a few packages installed inevitably:
~ $ eix -I gnome --compact
[I] dev-cpp/libgnomecanvasmm (2.26.0(2.6)@10/27/2011): C++ bindings for libgnomecanvas
[U] gnome-base/gnome-common (2.28.0(3)@05/05/2010 -> 3.1.0(3)): Common files for development of Gnome packages
[I] gnome-base/gnome-mime-data (2.18.0@10/18/2009): MIME data for Gnome
[I] gnome-base/libgnomecanvas (2.30.3@10/27/2011): The Gnome 2 Canvas library
[U] gnome-base/libgnomeprint (2.18.6(2.2)@10/18/2009 -> 2.18.8(2.2)): Printer handling for Gnome
[I] gnome-extra/gnome-audio (2.22.2@09/06/2011): Gnome Desktop Sound Effects Package
[I] media-video/gnome-mplayer (1.0.5@01/16/2012): A GTK+ interface to MPlayer
[I] x11-themes/gnome-icon-theme (3.2.1.2@12/31/2011): GNOME default icon theme
Found 8 matches.
I think a couple of them can be un-merged, but just not all.

As a Linux user, more or less, you need to compromise with a few packages or libraries. Linux is a diverse world, for just one task, you may be able to find ten libraries which can do the same job. When you find a program you like, it's possible that it uses a library you don't like.

That's what Linux is and that's the way it has been, but some people don't like that and other don't want any changes to it.

Since a few packages of GNOME on my system, I only concern if the number of depending packages will grow. And if GNOME become an OS, the situation may get complicated.

Luckily, because of open source, if you don't like something, you are allowed to do something about it. Like MATE, a fork and a continuation of GNOME2. Only you need skills instead of a bitching mouth.

Now, looking back at the time when Windows still a program you needed to type win to run it. It was a Desktop Environment, although Wikipedia uses different terms, such Graphical Environment or Operating Environment, even Operating System. But it was never a OS since it didn't handle low-level operations, not I know of. Until Windows 95, things were packed together, Windows became OS since then.

It seems unavoidable that a Desktop Environment would evolve into a full OS, one way or another. It may not be the desires of developers but the users', anyhow, that's the direction, even you don't like it.

Even so, you should be glad that it's a DE, not a program which reads mail.

After I posted my first try of OpenCDE, I wrote an email to the developer and he sent me very useful information:
The problem that you are describing with multiple monitors could be due to the fact that OpenCDE uses the Motif Window Manager. This comes with OpenMotif and as such has not been updated for quite some time. AFAIK mwm does cause problems with multiple screens.

A solution to your problem could be to install the LessTif package, recompile wxWidgets to use LessTif (rather than OpenMotif) and then rebuild OpenCDE. This may help because LessTif provides it's own version of Motif Window Manager (based off fvwm) which may work better with multiple screens. Please be aware however that LessTif is generally less stable than OpenMotif so may introduce other bugs. A fork of mwm is planned so I can fix these bugs and maintain the software via the OpenCDE project (as dtwm)

I downloaded the LessTif 0.95.2 and installed it (it's not Gentoo Portage tree), everything went smoothly. But after I entered OpenCDE, it immediately exited. The only thing I saw was Mwm Pager.

I decided to remove OpenMotif package because I felt confused when I configured wxMotif, wxMotif didn't provide an option for you to choice which one (OpenMotif or LessTif) you would like to use. Maybe it's dynamic by `wx-config`? I don't know, the whole wx thing is not so clear to me.

Anyway, after removed OpenMotif and re-compiled, it works. However, it's still has some issue with LessTif. I can not make window move/expand/etc normally in external screen. But I still can make those operation in my original screen, then pan in Mwm Pager.

Here is a latest screenshot:


There is one more small thing I would like to point out in that screenshot. See that little icon between htop and browser? Oh boy, that's so cute as if I was back to 90's. It was a minimized window.

Before I was going to take a screenshot I encountered another problem with LessTif. I wasn't able to switch window focus after I brought up conky and xcompmgr, I wasn't sure they were the cause but the mouse clicks were still registered in each program (not keyboard inputs), I still could log out.

As for memory usage, `mwm` used 3.3 MB (4.8 MB, OpenMotif's mwm). The rest doesn't seem changed.

Well, I think that's all.